To Do Lists

Certain events that occur within the system will trigger messages describing work that requires attention.  For example, if a bill segment has an error, the system generates a To Do message to alert the person responsible for correcting such errors.

Each type of message represents a To Do list.  For example, there are To Do lists for bill segment errors, payment errors, accounts without bill cycles, etc. 

We refer to each message as a To Do Entry.  Each To Do entry is assigned a specific To Do Role.  The role defines the users who may work on the entry.  A To Do entry has a To Do log that maintains record of the progress on the To Do entry.  For example, the To Do log indicates when the To Do entry was created, when it was assigned to a user and to whom it was assigned, and when and by whom it was completed. 

Contents

The Big Picture of To Do Lists

Setting Up To Do Options

The topics below provide more information about To Do configuration.

Contents

To Do Entries Reference A To Do Type

To Do Entries Reference A Role

To Do Entries Can Be Rerouted (Or Suppressed) Based On Message Number

The Priority Of A To Do Entry

Working On A To Do Entry

Launching Scripts When A To Do Is Selected

To Do Entries Have Logs

How Are To Do Entries Created?

The Lifecycle Of A To Do Entry

Linking Additional Information To A To Do Entry

Implementing Additional To Do Entry Business Rules

To Do Entries May Be Routed Out Of The System

Periodically Purging To Do Entries

To Do Entries Reference A To Do Type

Every To Do entry references a To Do type.  The To Do type controls the following functions:

·         The To Do list on which the entry appears.  

·         The page into which a user is taken when they drill down on an entry.

·         The message that appears in the user’s To Do list.  Note this message can be overridden for specific To Do messages by specifying a different message number in the process that creates the specific To Do entry.  For example, the process that creates To Do entries associated with bill segments that are in error displays the error message rather than a generic “bill segment is in error” message.

·         The To Do list’s sort options.  Sort options may be used on the To Do list page to sort the entries in a different order.  For example, when a user looks at the bill segment error To Do list, they have the option of sorting it in error number order, account name order, or in customer class order.  Note the default sort order is also defined on To Do type.

·         Whether (and how) the To Do entry is downloaded to an external system (e.g., an email system).

·         The roles to which an entry may be reassigned.

·         The default priority of the To Do list in respect of other To Do lists.

·         The To Do list’s usage, which indicates whether a To Do of that type may be created manually by a user.

·         The algorithms used to perform To Do list specific business rules.

·         The characteristics applicable to the To Do list.

To Do Entries Reference A Role

Every To Do entry references a role.  The role defines the users who may be assigned to Open entries.

The permissible roles that may be assigned to a To Do entry are defined on the entry’s To Do type.  After an entry is created, its role may be changed to any role defined as valid for the entry’s To Do type.

An entry’s initial role is assigned by the background process or algorithm that creates the entry.  Because you can create your own processes and algorithms, there are an infinite number of ways to default an entry’s role.  However, the base package processes and algorithms use the following mechanisms to default an entry’s role:

·         The system checks if an entry’s message category / number is suppressed (i.e., not created).  If so, the entry is not created.  Refer to To Do Entries Can Be Rerouted Or Suppressed Based On Message Number for more information.

·         The system checks if an entry’s message category / number is rerouted to a specific role.  If so, it defaults this role.  Refer to To Do Entries Can Be Rerouted Or Suppressed Based On Message Number for more information.

·         Your specific product may introduce additional criteria for assigning a role (see To Do Lists and To Do Roles in the product help index).

·         If a role wasn’t retrieved in the previous step AND if the entry is created via an algorithm that has Role as a parameter, this role is assigned to the entry.  Note: role is frequently an optional parameter of algorithms.

·         If the entry does not have a role after the above takes place, the entry’s To Do type’s default role is assigned to the entry.  The system provides a default role assigned to the system To Do types called F1_DFLT.

To Do Entries Can Be Rerouted (Or Suppressed) Based On Message Number

Consider the To Do type used to highlight bill segments that are in error.  To Do entries of this type reference the specific bill segment error number so that the error message can be shown when the Bill Segments in Error To Do list is displayed. 

If you want specific types of errors to be routed to specific users, you can indicate such on the To Do type.  For example, if certain bill segment errors are always resolved by a given rate specialist, you can indicate such on the To Do type.  You do this by updating the To Do type's message overrides.  On this page you specify the message category / number of the error and indicate the To Do role of the user(s) who should work on such errors.  Once the To Do type is updated, all new To Do entries of this type that reference the message number are routed to the desired role.

Obviously, you would only reroute those To Do types that handle many different types of messages.  In other words, if the To Do type already references a specific message category / number rerouting is not applicable.

We do not supply documentation of every possible message that can be handled by a given To Do type.  The best way to build each To Do type’s reroute list is during the pre-production period when you’re testing the system.  During this period, compile a list of the messages that should be routed to specific roles and add them to the To Do type.

Keep in mind that if a message number / category is not referenced on a To Do type’s reroute information, the entry is routed as described under To Do Entries Reference A Role.

The Priority Of A To Do Entry

Some To Do entries may be more urgent to resolve than others.  A To Do entry is associated with a priority level representing its relative processing order compared to other entries. 

Priority level is initially assigned as follows:

·         If a Calculate Priority plug-in is defined on the To Do entry's type, the system calls it to determine the entry's priority. You may want to use this method if an entry's priority is based on context or time-based factors.  For example, when priority takes into consideration account specific attributes.  When applicable, you may design a process that triggers priority recalculation of To Do entries "at will".  For example, when priority is reassessed periodically based on factors external to the To Do entry's information.  Refer to To Do Type for more information on priority calculation algorithms.

·         If a priority value has not been determined by a plug-in, the system defaults a To Do entry's initial priority to the value specified on its type.

A user may manually override a To Do entry's priority at any time.  Notice that once a To Do entry's priority is overridden, Calculate Priority plug-ins are no longer called so as to not override the value explicitly set by the user.

Working On A To Do Entry

A user can drill down on a To Do entry.  When a user drills down on an entry, the user is transferred to the transaction associated with the entry.  For example, if a user drills down on a bill segment error entry, the user is taken to the Bill Segment – Main page.  Obviously, the page to which the user is taken differs depending on the type of entry.

It is also possible to configure the To Do type to launch a script when a user drills down on an entry rather than taking the user to a transaction.  The script would walk the user through the steps required to resolve the To Do entry.  Refer to Launching Scripts When A To Do Is Selected for more information.

After finishing work on an entry, the user can mark it as Complete.  Completed entries do not appear on the To Do list queries (but they are retained on the database for audit purposes).  If the user cannot resolve the problem, the user can forward the To Do to another user.

Launching Scripts When A To Do Is Selected

Users can complete many To Do entries without assistance.  However, you can set up the system to launch a script when a user selects a To Do entry.  For example, consider a To Do entry that highlights a bill that's in error due to an invalid mailing address.  You can set up the system to execute a script when this To Do entry is selected by a user.  This script might prompt the user to first correct the customer's default mailing address and then re-complete the bill.

A script is linked to a To Do type based on its message number using the To Do type's message overrides.  Refer to Executing A Script When A To Do Is Selected for more information.

To Do Entries Have Logs

Each To Do entry has a To Do log that maintains a record of the To Do’s progress in the system.  For example, the To Do log indicates when the To Do entry was created, when it was assigned to a user and to whom it was assigned, and when and by whom it was completed.  Users can view the log to see who assigned them a particular To Do and whether any work has already been done on the To Do.

A log entry is created for all actions that can be taken on a To Do entry.  Log entries are created for the following events:

·         A To Do entry is created (either by the system or by a user)

·         A To Do entry is completed (either by the system or by a user)

·         A user takes an open To Do entry

·         A supervisor assigns a To Do entry

·         A user forwards an entry to another user or role

·         A user sends back a To Do to the user who forwarded it

·         A user manually adds a log entry to record details about the To Do’s progress

·         A user manually overrides the To Do entry's priority

How Are To Do Entries Created?

A To Do Entry may be created in the following ways:

·         A background process can create To Do Entries.

·         An algorithm can create entries of a given type.  Because the use of algorithms is entirely dependent on how you configure the control tables, the number of types of such entries is indeterminate. 

·         A user can create entries of To Do types that have a Manual usage.  Refer to To Do Entries Created Manually for information about setting up manual To Do types.

·         An XAI service may create an entry of a given type.

For any base product process (background process, algorithm, XAI service, etc) that includes logic to create a To Do entry, the system supplies a sample To Do type that may be used.  Although the To Do types provided by the product are system data, the following information related to each To Do type may be customized for an implementation and is not overwritten during an upgrade:

·         The creation process.  If the To Do is created by a background process where the background process is referenced on a To Do type.  Refer to To Do Entries Created By Background Processes for more information.

·         The routing process.  Refer to To Do Entries May Be Routed Out of the System for more information.

·         The priority.  Refer to To Do Type - Main for more information.

·         The roles that may be associated with the To Do type.  Refer to To Do Entries Reference a Role for more information. 

·         The message override information.  Refer to To Do Entries Can Be Rerouted (Or Suppressed) and Launching Scripts When a To Do Is Selected for more information.

Contents

To Do Entries Created By Background Processes

To Do Entries Created By Algorithms

To Do Entries Created Via an XAI Service

To Do Entries Created Manually

To Do Entries Created By Background Processes

There are different types of To Do entries created by background processes:

·         To Do entries created by dedicated To Do background processes

·         To Do entries created for object-specific errors detected in certain background processes

·         To Do entries created based on a specific condition

Contents

Dedicated To Do Background Processes

To Dos Created for Object-Specific Error Conditions

To Dos Created by Background Processes for Specific Conditions

Dedicated To Do Background Processes

There are To Do entries that are created by system background processes whose main purpose is to create To Do entries based on a given condition.   For these background processes, the To Do Type indicates the creation background process.

To Dos Created for Object-Specific Error Conditions

A system background process may create a To Do entry when an error is detected during object-specific processing and it is not possible to create an exception record.  (I.e., either no exception record exists for the process or the error is not related to the entity reported in the exception record.)

For these background processes, the To Do Type must reference the creation background process.  To have the system create To Do entries for some or all of the errors generated by one of these processes, you must do the following:

·         If you want the system to generate To Do entries for errors detected by one of the background processes below, go to the appropriate To Do type and populate the creation background process. 

·         If you want the system to generate To Do entries for some errors for the process, but not for all errors, populate the creation background process and then proceed to the message overrides tab to suppress certain messages.   To this by indicating the message category and message number you want to suppress.  Any error that is suppressed is written to the batch run tree. 

If you do not populate the creation background process, the errors are written to the batch run tree.

To Dos Created by Background Processes for Specific Conditions

There are some system background processes that create a To Do entry when the process detects a specific condition that a user should investigate.  For each background process, the To Do type is an input parameter to the process.  The system provides To Do types for each base package background process that may create a To Do entry. 

To Do Entries Created By Algorithms

There are To Do entries that are created by algorithm types supplied with the base package.  The system supplies a To Do Type for each of these To Do entries that you may use. 

If you want to take advantage of these types of entries for system algorithm types, you must do the following:

·         Create an algorithm: 

·         This algorithm must reference the appropriate Algorithm Type. 

·         These algorithms have a parameter of the To Do Type to be created.   You should specify the To Do Type indicated in the table.

·         Plug the algorithm into the respective control table. 

To Do Entries Created Via an XAI Service

There are some XAI services supplied with the base package that create To Do entries.  The system provides a To Do type for each base package XAI service that may create a To Do entry. 

XAI services do not have parameters where a To Do type can be plugged in.  As a result, each service must be designed to determine the To Do type appropriately.  You may choose to use a feature configuration option to define the To Do type.  Refer to the documentation for the base package services that create a To Do entry to determine how the To Do type is determined.

To Do Entries Created Manually

You must set up manual To Do entry types if you want your users to be able to create To Do entries online.  Users may create a manual To Do entry as a reminder to themselves to complete a task.  Online To Do entries may also be used like electronic help tickets in the system.  For example, if a user is having a problem starting service, the user can create a To Do that describes the problem.  The To Do can be assigned to a help resolution group that could either resolve the problem or send the To Do back to the initiating user with information describing how to resolve the problem.

If you want to take advantage of manual To Do entries, create a To Do type and specify the following information.

On the Main tab:

·         Set the To Do Type Usage flag to Manual.

·         Set the Navigation Option to toDoEntryMaint (To Do entry maintenance).

·         Set the Message Category and Message Number to the message you want to be used for To Do entries of this type.  A generic base message is provided (category 15, message 1000) that can be used for manual To Dos.  If you use this message, the To Do's subject appears as the message for the To Do. 

On the Roles tab:

·         Specify the To Do roles that may be assigned to To Do entries of this type. 

·         Indicate the To Do role that should be defaulted when you create To Do entries of this type.

On the Sort Keys tab:

When a user adds a manual To Do entry, the system creates an entry with three sort key values.  (Sort keys may be used on the To Do list page to sort the entries in a different order.)  The To Do type should be set up to reference the sort keys as follows:

Sequence	Description
1	Created by user ID
2	Created by user name
3	Subject

We recommend that the keys have an Ascending sort order and that the Subject is made the default sort key.

On the Drill Keys tab:

When a user adds a manual To Do entry, it is created with a drill key value equal to the To Do entry’s ID.  When the user clicks the Go To button next to the message in the To Do list, the system uses the drill down application service (defined on the main tab) and the drill key to display the associated To Do entry.

The To Do type should be set up with a drill key that reference the To Do entry table and the To Do entry ID:

Sequence	Table	Field
1	CI_TD_ENTRY	TD_ENTRY_ID

The Lifecycle Of A To Do Entry

The following state transition diagram will be useful in understanding the lifecycle of a To Do entry.

A To Do entry is typically created in the Open state.  Entries of this type can be viewed by all users belonging to the entry’s role.  Refer to How Are To Do Entries Created? for information about how entries are created.

An Open entry becomes Being Worked On when it is assigned to a specific user or when a user proactively assumes responsibility for the entry.  While an entry is Being Worked On, it is visible on the To Do Summary page only by the user who is assigned to it.

A Being Worked On entry may be forwarded to a different user or role.  If the entry is forwarded to a role, it becomes Open again.

When an entry becomes Complete, it is no longer visible in the To Do list queries (but it remains on the database for audit purposes).  There are two ways an entry can become Complete:

·         A user can manually indicate it is Complete (there are several ways to do this).

·         For To Do entries that are logically associated with the state of some object, the system automatically marks the entry Complete when the object is no longer in the respective state.  For example, an entry that’s created when an account doesn’t have a bill cycle is completed when the account has a bill cycle. 

Linking Additional Information To A To Do Entry

Additional information may be linked to a To Do entry using characteristics.  For example, when creating a manual To Do entry, a user may define the account related to the To Do.  

When creating an automatic To Do entry, the program that generates the To Do may link related data to the To Do using characteristics.  Use system algorithm to link related entities.  For manually created To Dos, the valid characteristic types that may be linked to the To Do entry must be defined on the To Do type for that To Do entry.

If your To Do entries reference characteristics that are related to your global context data, you may want to configure an control central alert algorithm to display an alert if a related entry is Open or Being Worked On. 

Implementing Additional To Do Entry Business Rules

If your business practice calls for additional validation rules or processing steps to take place after a To Do Entry is created or updated, you may want to take advantage of the To Do Post Processing plug-ins defined on To Do type.

For example, you may want to validate that To Do entries are only assigned to users with the proper skill levels needed to resolve them.  Refer to F1-VAL-SKILL for a sample algorithm handling such validation.

To Do Entries May Be Routed Out Of The System

A To Do type can be configured so that its entries are interfaced to another system.  For example, a given To Do type can be configured to create an email message whenever a new To Do entry is created.  The following points describe how to do this:

·         Define the name of the background process responsible for interfacing the new To Do entries to another system on the respective To Do type.  The base package contains a batch process called F1-TDEER that can be used for most situations.  This batch process invokes the External Routing algorithms defined on each entry's To Do type. 

·         Plug in an appropriate External Routing algorithm on the respective To Do type.  The logic in this type of algorithm performs the interface efforts for a specific To Do entry.  For example, if an email message should be created for a To Do entry, the logic in the algorithm would compose and send the email message(s) for a specific To Do entry.   While algorithms of this type can contain any type of logic, the following points highlight the configuration tasks that are necessary to create an email message in such an algorithm:

·         Create an XAI Sender as follows:

·         Invocation Type: MPL

·         XAI Class: Post Messages To Email

·         The SMTP Host name should be your implementation's email server.

·         Create an Outbound Message Type with a Business Object of F1-EmailMessage

·         Create an External System to represent the email system.  It should have a single entry that references the XAI Sender and Outbound Message Type referenced above.  This entry will have a Processing Method of XAI.

·         Create a To Do type External Routing algorithm that:

·         Formats the email message by populating elements in the business object referenced on the Outbound Message Type created above.  Note: this email can contain hyperlinks to the source application as well as a summary of information about the To Do entry and its related objects.

·         Creates an outbound message by adding the business object formatted in the previous step.

Please note that most products contain example External Routing algorithm types that can be used as a basis for your own.

·         Plug in the External Routing algorithm on the respective To Do type.

Click here to see the algorithm types available for this system event.

Periodically Purging To Do Entries

Completed To Do entries should be periodically purged from the system by executing the TD-PURGE background process.  This background process offers you the following choices:

·         You can purge all To Do entries older than a given number of days.

·         You can purge a specific To Do type’s To Do Entries that are older than a given number of days.

We want to stress that there is no system constraint as to the number of Completed To Do entries that may exist.  You can retain these entries for as long as you desire.  However, you will eventually end up with a very large number of Completed entries and these entries will cause the various To Do background processes to degrade over time.  Therefore, you should periodically purge Completed To Do entries as they exist only to satisfy auditing and reporting needs.

The topics in this section describe how to set up To Do management options.

Contents

Installation Options

Messages

Feature Configuration

Defining To Do Roles

Defining To Do Types

List of System To Do Types

Implementing The To Do Entries

Installation Options

The following section describes configuration setup on the installation options.

Contents

To Do Information May Be Formatted By An Algorithm

Set Additional Information Before A To Do Is Created

Control Central Alerts

Next Assignment Algorithm

To Do Information May Be Formatted By An Algorithm

A To Do Information algorithm may be plugged in on the installation record to format the standard To Do information that appears throughout the system.  This algorithm may be further overridden by a corresponding plug-in on the To Do Type. 

Set Additional Information Before A To Do Is Created

A To Do Pre-creation algorithm may be plugged in on the installation record to set additional information for a To Do entry before it is created.

For example, Oracle Utilities Customer Care and Billing provides an algorithm that attempts to link (using characteristics) a related person, account, premise, service agreement or service point to a To Do entry based on its drill key value.  Note, before you can set up this algorithm, you must define the characteristic types that you'll use to hold each of these entities. 

Another example from Oracle Utilities Customer Care and Billing is that it provides an algorithm to determine a To Do role based on account management group and division information.

Control Central Alerts

If your To Do entries reference characteristics that related to your global context data, you may want to configure an alert algorithm plugged into the installation options to display an alert if the entry is Open or Being Worked On. 

For example, Oracle Utilities Customer Care and Billing provides an alert algorithm that displays an alert when a To Do in this status exists for the account, person or premise displayed in the current context.  Refer to Linking Additional Information To A To Do Entry for more information.

Next Assignment Algorithm

If your organization opts to use the next assignment feature supported by the Current To Do dashboard zone, you need to plug-in a Next To Do Assignment algorithm into the installation options to determine the next To Do entry the user should work on.  Make sure you provide users with security access rights to the zone's next assignment action. 

Messages

You need only set up new messages if you use algorithms to create To Do entries or prefer different messages than those associated with the base package’s To Do types.

Feature Configuration

The base package is provided with a generic Activity Queue Management Feature Configuration type.  You may want to set up a feature configuration of this type to define any To Do management related options supporting business rules specific to your organization.   

For example, the base package provides the following plug-ins to demonstrate a business practice where To Do entries are only assigned to users with the proper skill levels to work on them.

·         The base To Do Post Processing To Do Type algorithm F1-VAL-SKILL validates that a user has the necessary skill levels required to work on a given To Do entry.

·         The base Next To Do Assignment installation options algorithm F1-NEXT-ASSG only assigns To Do entries to users that have the proper skills to work on them.  This plug-in is only applicable if your organization practices work distribution "on demand".

You must set up such an Activity Queue Management feature configuration if you want to use any of the above base package plug-ins. 

The following points describe the various Option Types provided with the base package:

·         Skill.  This option provides a reference to a skill category.  For example, if you were using characteristics to represent skill categories then you should reference each characteristic type using this option.

·         Override Skill.  This option provides an override skill information reference for a specific message.  For example, if you were using a To Do Type characteristic to specify an override skill category and level for a specific message category / number then you would reference this characteristic type using this option.

Defining To Do Roles

This section describes the control table used to maintain To Do roles.

Contents

To Do Role - Main

To Do Role - To Do Types

To Do Role - Main

The Main notebook page is used to define basic information about a To Do role. 

To maintain this information, select Admin Menu, To Do Role and navigate to the Main page.

Description of Page

Enter a unique To Do Role and Description for the To Do role.

The grid contains the ID of each User that may view and work on entries assigned to this role.  The First Name and Last Name associated with the user is displayed adjacent.

Where Used

Follow this link to view the tables that reference CI_ROLE in the data dictionary schema viewer.

In addition, a role may be defined as a parameter of an algorithm.

To Do Role - To Do Types

The To Do Types page defines the To Do types that may be viewed and worked on by users belonging to a given To Do role. 

To maintain this information, select Admin Menu, To Do Role and navigate to the To Do Types page.

Description of Page

Enter the ID of each To Do Type whose entries may be viewed and worked on by the role.

Use As Default is a display-only field that indicates if the role is assigned to newly created entries of this type.  You may define the default role for a given To Do type on the To Do Type maintenance page.

Defining To Do Types

This section describes the control table used to maintain To Do types.

Contents

To Do Type - Main

To Do Type - Roles

To Do Type - Sort Keys

To Do Type - Drill Keys

To Do Type - Message Overrides

To Do Type - To Do Characteristics

To Do Type - Algorithms

To Do Type - Main

The Main notebook page is used to define basic information about a To Do type. 

To maintain this information, select Admin Menu, To Do Type and navigate to the Main page.

Description of Page

Enter a unique To Do Type and Description for the To Do type.

Owner indicates if this entry is owned by the base package or by your implementation (Customer Modification).

Use the Detailed Description to provide further details related to the To Do Type.

Enter the default Priority of To Do entries of this type in respect of other To Do types.  Refer to The Priority Of A To Do Entry for more information.

For To Do Type Usage, select Automatic if To Dos of this type are created by the system (i.e., a background process or algorithm).  Select Manual if a user can create a To Do of this type online.

Define the Navigation Option for the page into which the user is transferred when drilling down on a To Do entry of this type.

Use Creation Process to define the background process, if any, that is used to manage (i.e., create and perhaps complete) entries of this type.  A Creation Process need only be specified for those To Do types whose entries are created by a background process.  Refer to To Do Entries Created By Background Processes for more information.

Use Routing Process to define the background process that is used to download entries of a given type to an external system, if any.  A Routing Process need only be specified for those To Do types whose entries are routed to an external system (e.g., an Email system or an auto-dialer).  Refer to To Do Entries May Be Routed Out Of The System for more information.

Use Message Category and Message Number to define the message associated with this To Do type’s entries.  Note: this message will only be used if the process that creates the To Do entry does not supply a specific message number.  For example, the process that creates To Do entries that highlight bill segments that are in error would not use this message; rather, the entries are marked with the message associated with the bill segment’s error.

Use the characteristics collection to define a Characteristic Type and Characteristic Value common to all To Do entries of this type.  You may enter more than one characteristic row for the same characteristic type, each associated with a unique Sequence number.  If not specified, the system defaults it to the next sequence number for the characteristic type.

Where Used

Follow this link to view the tables that reference CI_TD_TYPE in the data dictionary schema viewer.

To Do Type - Roles

The Roles page defines the roles who may view and work on entries of a given To Do type. 

To maintain this information, select Admin Menu, To Do Type and navigate to the Roles page.

Description of Page

Enter each To Do Role that may view and work on entries of a given type.  Turn on Use as Default if the role should be assigned to newly created entries of this type.  Only one role may be defined as the default per To Do type. 

To Do Type - Sort Keys

The Sort Keys page defines the various ways a To Do list’s entries may be sorted.  For example, when you look at the bill segment error To Do List, you have the option of sorting the entries in error number order, account name order, or in customer class order. 

To maintain this information, select Admin Menu, To Do Type and navigate to the Sort Keys page.

Description of Page

The following fields display for each sort key.

Sequence                                            The unique ID of the sort key.

Description                                          The description of the sort key that appears on the To Do list.

Use as Default                                      Turn this switch on for the default sort key (the one that is initially used when a user opens a To Do list).  Only one sort key may be defined as the default per To Do type. 

Sort Order                                            Select whether the To Do entries should be sorted in Ascending or Descending order when this sort key is used.

Owner                                                 Indicates if this entry is owned by the base package or by your implementation (Customer Modification).

To Do Type - Drill Keys

The Drill Keys page defines the keys passed to the application service (defined on the Main page) when you drill down on an entry of a given type.

To maintain this information, select Admin Menu, To Do Type and navigate to the Drill Keys page.

Description of Page

Navigation Option shows the page into which the user is transferred when drilling down on a To Do entry of this type.

The following fields display for each drill key.

Sequence                                            The unique ID of the drill key.

Table and Field                                    The table and field passed to the application service when you drill down on an entry of a given type.

Owner                                                 Indicates if this entry is owned by the base package or by your implementation (Customer Modification).

To Do Type - Message Overrides

The Message Overrides page is used if you want To Do entries that reference a given message category / number to be routed to a specific To Do role (or suppressed altogether) or if you want to associate a script to a given message category / number. 

To maintain this information, select Admin Menu, To Do Type and navigate to the Message Overrides page.

Description of Page

The following fields display for each override.

Message Category and Number           The identity of the message to be overridden.

Exclude To Do Entry                            Turn on this switch if a To Do entry of this type that references the adjacent Message Category and Number should NOT be created.

Override Role                                      Specify the role to which a To Do entry of this type that references the adjacent Message Category and Number should be addressed.  This field is protected if Exclude To Do Entry is on (you can’t reroute an entry to a specific role if it’s going to be excluded).

Script                                                   Indicate the script that you would like to execute when a user drills down on a To Do entry of this type that references the adjacent Message Category and Number.  This field is protected if Exclude To Do Entry is on.  Refer to Working On A To Do Entry for more information.

To Do Type - To Do Characteristics

The To Do Characteristics page defines characteristics that can be defined for To Do entries of this type. 

To maintain this information, select Admin Menu, To Do Type and navigate to the To Do Characteristics page.

Turn on the Required switch if the Characteristic Type must be defined on To Do entries of this type. 

Enter a Characteristic Value to use as the default for a given Characteristic Type when the Default switch is turned on.  Use Sequence to control the order in which characteristics are defaulted.

To Do Type - Algorithms

The To Do Algorithms page defines the algorithms that should be executed for a given To Do type. 

To maintain this information, select Admin Menu, To Do Type and navigate to the Algorithms page.

Description of Page

The grid contains Algorithms that control important To Do functions.  If you haven’t already done so, you must set up the appropriate algorithms in your system.  You must define the following for each algorithm:

·         Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).

·         Specify the Sequence Number and Algorithm for each system event.  You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms.  In this case, you need to tell the system the Sequence in which they should execute.

The following table describes each System Event.

System Event	Optional / Required	Description
Calculate Priority	Optional	Algorithms of this type may be used to calculate a To Do entry's priority.  They are called initially when a To Do entry is created and each time it gets updated so long as the To Do entry's priority has not been manually overridden.  Once overridden, these algorithms are not called anymore.  Note that it is not the responsibility of the algorithms to actually update the To Do entry with the calculated priority value but rather only return the calculated value.  The system carries out the update as necessary. If more than one algorithm is plugged-in the system calls them one by one until the first to return a calculated priority. Click here to see the algorithm types available for this system event.
External Routing	Optional	Algorithms of this type may be used to route a To Do entry to an external system.  The base package F1-TDEER background process invokes the algorithms for every To Do entry that its type references the process as the Routing Process and that the entry was not already routed.  The background process marks an entry as routed by updating it with the batch control’s current run number.  If more than one algorithm is plugged-in the batch process calls them one by one until the first to indicate the To Do entry was routed.  Click here to see the algorithm types available for this system event.
To Do Information	Optional	We use the term “To Do information” to describe the basic information that appears throughout the system to describe a To Do entry.  The data that appears in “To Do information” is constructed using this algorithm.  Plug an algorithm into this spot to override the "To Do information" algorithm on installation options or the system default “To Do information” if no such algorithm is defined on installation options. Click here to see the algorithm types available for this system event.
To Do Post-Processing	Optional	Algorithms of this type may be used to validate and/or further process a To Do entry that has been added or updated. Click here to see the algorithm types available for this system event.

List of System To Do Types

Implementing The To Do Entries

To enable the To Do entries listed above, you must configure the system as follows:

·         Refer to How Are To Do Entries Created? for more information related to To Do entries created by background processes and algorithms.

·         Define the To Do roles associated with each To Do type and link the appropriate users to them.    Once you have defined the roles appropriate for your organization's To Do types, remove the reference to this system default role F1_DFLT.  Refer to To Do Entries Reference A Role for more information.